Method, device and software product for filling an address field of an electronic message

ABSTRACT

A content, context or the like as entered by a user may be used to automatically evaluate a recipient or recipients to whom the message is directed. A method for filling a recipient address field of an electronic message in a messaging application executable on a communication terminal begins by selecting a content chunk from a content area of said message and deciding whether said content chunk matches a predefined addressee identifier pattern. If the content chunk matches a predefined addressee identifier pattern then the a name portion is extracted from the content chunk. The name portion is compared with entries in a predefined directory. It the name portion matches an entry then a recipient address proposal is created based on an address stored in the directory. That recipient address proposal is filled into said recipient address field of said message.

FIELD OF INVENTION

The present invention relates to a method for method for filling anaddress field of an electronic message. The invention also relates to acorresponding device and software product.

BACKGROUND OF THE INVENTION

An electronic message such as an email, SMS, or the like usuallyincludes a message body and a message head, optionally attachments. Themessage body usually is a single data field containing the main contentof the message in text form. Optionally, the text may be formatted andmay include hyper links, signature code or image, and/or embedded mediafiles. The message head usually includes a plurality of data fields andshould at least include a recipient address field (known as “To” field),and a sender address field (known as “From” field). Additionally, themessage head may include data fields dedicated for a subject text,addresses of an additional recipient (carbon copy recipient, known as“Cc” field) and/or a hidden additional recipient (blind carbon copyrecipient, known as “Bcc” field), and selectors like Relevancy, Privacy,Verification-of-Receipt, and others. The address fields usually areprepared for including one or more data items each representing a singleaddress. More than one item in an address field may be referred to as anaddress list which are, on a data level, usually separated by somedelimiting character(-s). The sender address field usually includes asingle sender address as a data item. In a messaging client's userinterface, each data field to be defined/filled by a user may berepresented by a tab or input box, a checkbox, a scroll menu, a controlbutton, or the like.

Currently, the only way to set the recipient address in an email is bymanually editing the recipient tab (or field). This method has thedrawback that it requires an explicit action. If someone wants to sendone same email massively to several recipients which do not belong to agroup, and each message should be personalised (like an email from abank or from a Human Resources (HR) department), the user has to repeatthis action hundreds or thousands of times.

Up to now the only methods existing to help in this problem is first theauto-complete feature which keeps in a cache a list of email accountsthat have been used (meaning sent to or received an email from them) andsuggests them by just typing some letters from the recipient's emailaccount in the recipient's tab. Second for the case of sending one sameemail to a large number of people that cannot be grouped, there is theOUTLOOK* “template” or “forms” method in which a user can createpersonalised templates or forms including the recipients account, savethem and use them in the future (note that terms marked by an asterisk(*) here and throughout this application may be subject to trademarkprotection by their respective owners; mentioning such terms in thisapplication is purely for illustrating the background or possibleapplication of the present invention).

An OUTLOOK* plug-in (“PhraseExpress”) is known to provide text modulesand a number of macros, which can be incorporated in the text modules.Such macros allow for automatic adaptation of a text module to thepresent requirements (e.g. one macro may determine the gender of arecipient and another macro uses this to adapt the salutationaccordingly). The already filled “To” field, other (marked) emails, etc.are used by the macros to pick up the required information.

The sender address field is usually filled automatically by the emailclient's main algorithm. In case a user uses more than one email clientand/or addresses simultaneously, the user may manually select or fillthe proper address in the sender address tab.

An object of the present invention is to provide a method, a device anda software product for filling an address field of an electronic messagewhich are able to at least partly alleviate the drawbacks of the priorart as mentioned above. In particular, an object of the presentinvention is to provide such a method, device and software product whichare able to alleviate, minimise or even eliminate the further actionsneeded for setting the recipient address and/or sender address.

The aforementioned object or objects of the invention is/are solved atleast in parts by the features of the independent claims. Advantageousembodiments and further developments of the invention are set forth inthe subclaims.

SUMMARY OF THE INVENTION

The basic idea of the present invention is to automatically fill anaddress field, i.e., a recipient and/or sender address field, of anelectronic message by using the context of the message to extract theneeded information and then append it to the appropriate entry.

It will be noted that a message in the sense of the invention isunderstood to be a data structure (data set) which is separated intodifferent data fields which in turn may consist of one or more dataitems (but may also be empty except some mandatory fields). Any messagetype usually at least includes a header and a body where the headerusually at least includes a recipient address as a data field, and thebody includes a message text. Most message types also include a senderaddress and a subject, as data fields of the header. Many message types(such as emails) include not only one recipient address filed butinclude a main recipient address field (usually referred to as “To”field), a secondary recipient address field (usually referred to as “Cc”field for “Carbon copy”), and a hidden recipient address field (usuallyreferred to as “Bcc” field for “Blind carbon copy”) which are alladdress fields in the sense of the invention, and may be altogetherreferred to as an address area. Any address field may contain aplurality of addresses each of which forms a data item. Further datafields may contain control information (such as relevancy information orrequested confirmation of receipt), file attachments, and others. As notonly the body but also the subject may contain individual informationwhich may be evaluated, both body and subject are referred to as contentfields, and as a content area altogether, in the sense of the presentinvention. Any data field except the (main or only) recipient addressfield usually may be left empty while still defining a valid message.The body may contain pure text or formatted text. It is noted thatcontrol items are usually of fixed form, address fields are usuallycontrolled by a messaging client so as to meet a certain data formatprescribed by the messaging protocol, and may be verified with a globaladdress server so as to meet a valid address, and content fields areusually freely configurable while in some contexts may be limited inlength.

Therefore, a first aspect of the invention is a method for filling arecipient address field of an electronic message in a messagingapplication executable on a communication terminal connected to anetwork over which messages are sent, said method comprising the steps:

-   -   selecting a content chunk from a content area of said message;    -   deciding whether said content chunk matches a predefined        addressee identifier pattern; and    -   if said content chunk is decided to match said predefined        addressee identifier pattern:        -   extracting a name portion from said content chunk,        -   comparing said name portion with an entry of entries of a            predefined directory, and        -   if said name portion matches said entry:            -   creating a recipient address proposal based on an                address stored in said entry and suitable for a format                of the electronic message, and            -   filling said recipient address proposal into said                recipient address field of said message.                Electronic messaging has been widely used in the recent                decades. In this sense the electronic message may be,                for example, an email, an SMS, or the like, and may be                structured as explained above. Forwarding of the                electronic message may be accomplished by networks like                the internet, an intranet, a telephone network, a                cellular network, or a combination of those networks. An                address may be an email address, phone number, URL or                the like. A content area is a data area defining a                content which the sender wishes to transmit, and may                include a body, i.e., a main text content, and/or a                subject field of the message. In general, a content area                includes plain text but may also include formatted text                and/or embedded media. The inventive method\, however,                chiefly makes use of alpharethmetic content included in                the content area. A content chunk may be any fraction of                the content area. In particular the method implicitly                includes generating one or a plurality of content                chunks, by dividing the content. Chunk length may be                adapted to the length of said predefined addressee                identifier pattern; having more than one predefined                pattern may require repeating the dividing into chunks,                selection thereof and subsequent steps with different                chunk lengths. As a length of a name portion included in                a chunk is usually unknown in advance, the method may                start from a prescribed or determined maximum length,                and repeat the dividing, selecting and subsequent steps                with decreasing chunk lengths. A format of the                electronic message relates to the protocol used for                transmitting the message (e.g., e-mail, SMS, FTP, URL, .                . . ) and/or context (private/professional). The address                field may be any address field (main, secondary, hidden,                or one-and-only). Filling the address fields may be made                after each creation of said recipient address proposal,                or upon a certain condition, e.g., user interaction or                when writing of the message is finished.

The comparing and subsequent steps may be executed repeatedly in seriesand/or in parallel for a plurality of entries. The extracting andsubsequent steps may be executed repeatedly in series and/or in parallelfor a plurality of name portions found in a content chunk. The selectingand subsequent steps may be executed repeatedly in series and/or inparallel for a plurality of content chunks.

The predefined addressee identifier pattern may be taken from a patterncatalogue, wherein the deciding and further steps may be repeatedlyexecuted, regarding said content chunk, for any addressee identifierpattern provided in said pattern catalogue, wherein said patterncatalogue preferably may be sorted and/or scanned in the order ofdecreasing chunk length. The pattern catalogue may be editable by a userof said application. In this case, repeating the deciding and furthersteps may be stopped when a match is decided for one addresseeidentifier pattern because usually it is unlikely that a further matchwill be found. As longer addressee identifier patterns are taken first,matching precision may be enhanced. Adaptable means that patterns may beadded, changed, or deleted from the predefined pattern catalogue, byinteraction of said user, preferably by a user dialog.

The recipient address proposal may be a recipient address list, whereinsaid creating step may include adding said address stored in said entry,to said recipient address list; and said filling step may includefilling all or selected addresses from said recipient address list intosaid recipient address field. Selection may be made by user interaction,e.g., by manually picking or deleting some of them, and/or automaticallyby applying a predefined selection pattern. Such selection pattern may,e.g., include deletion of duplicates.

The method may include the further steps to be executed prior toexecuting said filling step:

-   -   offering said recipient address list to a user of said        application for selection and/or verification; and    -   discarding addresses not selected and/or verified by said user,        from said recipient address list.

Offering may preferably be accomplished by calling a user dialog; thisstep may be omitted if the recipient list is unambiguous.

The recipient address field may include a plurality of recipient addresssub-fields; and said recipient address list may include a plurality ofrecipient address sub-lists corresponding to said plurality of recipientaddress sub-fields, wherein said predefined pattern may be assigned toat least one of said recipient address sub-lists. A selection by theuser or user-selection mentioned above may include shifting an addressfrom one recipient address sub-list to another. Subfields may be, e.g.,previously mentioned “To”, “Cc”, “Bcc” fields. Assignment of saidpredefined pattern may be accomplished by applying rules allowing aprecise assignment to any of said sub-fields. E.g., a content chunk like“I will forward this message to Bill” may trigger a pattern match,extracting “Bill” as a name portion, seeking any Bill, William or thelike in the prename field of the application's or user's or a computer'sdirectory, and proposing any suitable address found in said directory,to be filled into the “Cc” sub-field.

The recipient address proposal may be offered to a user of saidapplication, upon explicit command by said user or automatically duringwriting of said message by said user. Said command may be a click on abutton or any suitable input or selection tool. Thereby, proposals maybe collected until the end of writing the message. In the secondalternative, any time a pattern match is found, the user may be giventhe opportunity to add a respective person's address to the recipientaddress field.

The method may include the further steps:

-   -   breaking said name portion into name fractions corresponding to        respective data fields in said directory, said name fractions        for example including at least one of a prename, surname, title,        and/or salutation; and    -   comparing said name portion with said entries of said directory        by name fractions.

A second aspect of the present invention is a method for filling asender address field of an electronic message in a messaging applicationexecutable on a communication terminal, said messaging applicationmanaging a plurality of sender addresses of a user of said application,said method comprising the steps:

-   -   selecting a content chunk from a content field of said message;    -   deciding whether said content chunk matches a predefined        addressee identifier pattern; and    -   if said content chunk is decided to match said predefined        addressee identifier pattern:        -   extracting a name portion from said content chunk,        -   comparing said name portion with at least one entry of            entries of a predefined directory, and        -   if said name portion matches one entry of said at least one            entry of entries of said directory:            -   creating a sender address proposal suitable for a format                of the electronic message, based on information stored                in said one entry of said directory, and            -   filling said sender address proposal into said sender                address field of said message.

This aspect of the present invention makes use of the conception thatknowing an addressee, i.e., recipient, of a message may indicate acontext per se of said message, and hence makes it possible to select asender address fitting said context. Information stored in an entry maybe, e.g., tags like family, job, etc., as found in a plurality ofaddress directories.

A third aspect of the present invention is a method for filling a senderaddress field of an electronic message in a messaging applicationexecutable on a communication terminal, said messaging applicationproviding a plurality of sender addresses of a user of said application,said method comprising the steps:

-   -   selecting a content chunk from a content field of said message;    -   deciding whether said content chunk matches a predefined        contextual pattern; and    -   if said content chunk is decided to match said predefined        contextual pattern:        -   creating a sender address proposal suitable for a format of            the electronic message, by selecting a sender address            fitting said contextual pattern, out of said sender            addresses of said user, and        -   filling said sender address proposal into said sender            address field of said message.

A pattern in the sense of this aspect may be any pattern which issuitable for identifying the context of the message, e.g., appellation,salutation, topic. Fitting may be evaluated by directly assigning eachpattern to a sender address, or by defining contexts or domains of saiduser, assigning each sender address and each contextual pattern to atleast one of said contexts or domains, and selecting a sender addresscontext or domain of which matches the contextual pattern's context ordomain.

The method of any of the preceding aspects may be executed at predefinedpoints of time, preferably periodically, during said message is beingwritten by a user. This allows adaptation of the recipient addressproposal, e.g., by narrowing likeliness of a certain entry.

In the method of any of the preceding aspects, said message may be anemail or an SMS, wherein the method is preferably executed in the formof an email application plug-in, e. g. OUTLOOK* plug-in, a browser ad-inor a mobile messaging application.

The method of any of the preceding aspects may be repeatedly executedfor a plurality of content chunks, said content chunks being generatedfrom a whole content area or selected parts thereof, wherein saidcontent chunk preferably is a first line altogether or a first linehaving characters of said message. This is a special case which may beparticularly easy to accomplish and low in processing load whilecovering a majority of cases. Alternatively, the content chunk may beselected from any part of the content area which would require a lot ofiterations, probably shifting the selection for content chunk characterby character, with varying chunk lengths.

In the method of any of the preceding aspects, said communicationterminal may be a server, client, desktop computer, portable computer,tablet, telephone, mobile phone, smart phone, PDA, or the like.

A further aspect of the present invention is a device being adapted toexecute a messaging application, said messaging application beingadapted to execute any of the afore-described methods, for filling arecipient and/or sender address field of an electronic message in amessaging application executable on said device. The device preferablyis a server, client, desktop computer, portable computer, tablet,telephone, mobile phone, smart phone, PDA, or the like.

A further aspect of the invention is a computer program product/softwareproduct for filling a recipient and/or sender address field of anelectronic message in a messaging application executable on acommunication terminal, said computer program product being stored oncomputer-readable medium, preferably being directly loadable into aninternal memory of a communication terminal, and including program codefor performing the steps of the afore-described method when saidcomputer program is executed by said communication terminal. Evidentlythe present invention may as well be embodied by a computer programincluding instructions causing a communication terminal to perform thesteps of the afore-described method when said computer program is loadedin or executed by said communication terminal, or by a digital datacarrier having electrically readable control signals which are designedto operate with a programmable computer, said control signals beingdesigned and adapted to cause the computer to perform the steps of theafore-described method. In any such cases, the computer may also beembodied by the device of the described aspect of the invention, acommunication device such as a mobile phone, smart phone or the like, aserver such as a collaboration server, call management server,conference server or the like, a personal computer or the like. Thesoftware product may be a plug-in, add-on, app or the like to beincluded in or used by or co-executed with said messaging application.

Further features, objects, advantages, and details of the presentinvention will become more apparent from the following description ofspecific embodiments of the invention and respective illustration in theappended drawings. Obviously, features, objects, advantages, and detailsof a specific embodiment, its variations and modifications mutatismutandis apply to other embodiments, variations and modifications unlesssuch application obviously violates technical constraints or laws ofnature. Embodiments may be combined with each other, and any combinationof an embodiment with another embodiment as a whole or in terms ofsingle features thereof may be assumed to constitute an embodiment ofthe invention.

Next, the invention is described referring to specific embodiments andreferring to the accompanying drawings.

BRIEF DESCRITPION OF THE DRAWINGS

FIG. 1 is a block diagram of a general outline of an email clientaccording to an embodiment the invention;

FIG. 2 is a representation of an email client user interface accordingto an embodiment of the invention;

FIG. 3 is a more detailed illustration of the email client generalstructure of FIG. 1 with exemplary functional implications according toan embodiment of the invention;

FIGS. 4A to 4C are flowcharts of respective sections of a processaccording to an embodiment of the invention; and

FIGS. 5 is a flowchart of a process according to another embodiment ofthe invention.

It is to be noted that the drawings are purely schematic and notnecessarily to scale. The drawings and descriptions are to illustratethe principle underlying the invention, rather than to limit theinvention in any way. The present invention is only limited by theappended claims.

DESCRIPTION OF THE PRESENT PREFERRED EMBODIMENTS

As mentioned above, a general idea of this application is to provide amethod that solves the problems mentioned above by eliminating thefurther actions needed for setting the recipient address of anelectronic message and doing this automatically by using the context ofthe message to extract the needed information and then append it to theappropriate entry.

The implementing concept of the present invention is described in thecontext of an email.

The invention starts out from the finding that a considerable amount ofthe emails sent between colleagues inside a company or between a companyand its clients use a formal format. In this format an email usuallystarts with the phrase like “Hello Mr./Mrs.” following the surnameand/or the first letter of the first name after a comma. Instead of“Hello” it is also common to have “Good morning” or “Good Evening” andinstead of “Mr./Mrs.” it is also known to use “Dr,” or somethingsimilar. Also, it is often used a symbol like “@” and then a name of aperson to whom the following text in the email content is referring. Allthese define popular patterns that almost everyone is using in emailcommunication. These patterns are going to be the configuration orotherwise the rules that will have to be agreed and may be setupinitially by the user or by default so that the method of the presentinvention can work. These patterns will be used as identifiers for themethod in order to detect the recipient's attributes upon which it willretrieve the actual recipient's email address. The definition of thesepatterns can be of any alpharethmetic (i. e., any string that can begenerated by characters acceptable and/or reproducible by the emailclient user interface) format, can be modified, enhanced or deleted atany time but they should be very precise in setting them up and inafterwards usage inside the mail content and there should always be atleast one. Default phrases may be set, e.g., to be “Hello Mr. Surname,”,“Hello Mrs. Surname,”, “Dear Mr. Surname,”, “Dear Mrs. Surname”, and soon.

Now, a basic functionality of the method will be described.

The method has to fulfil the following tasks.

A first process or process section is designed to parse the content ofthe email and try to match and identify the words or phrases that havebeen set up (e.g., by the user) in a configuration step as patterns. Theparsing in this context means that a content of the email is broken downinto chunks of content which are to be compared, one by one, with eachidentifier pattern so as to evaluate a possible match. Content chunksmay be of fixed length or variable length. Parsing may start from awhole content and may go down to levels of line or paragraph, sentenceor clause or even word or phrase. Here, parsing may reduce chunk lengthstep by step, so as to generate a vast number of content chunks. On theother hand, in a very simple parsing, only a first line of an email maybe chosen as a content chunk as a good percentage of information neededfor identifying a desired recipient may be found in this very firstline. Also, content is not limited to a body of the email but may alsobe extended to a subject field.

Assuming that a match is found of at least one pattern, in order tocontinue, the method moves to a second process or process section whichis to extract the name of the recipient. This can be done by reading theword after the pattern as it is set by the rules in the first step, e.g.“Hello Mr. Agathangelos,”, until a space or comma or dot is identified.After having extracted the name/s of the recipient/s, the method makes aquery to the directory that holds the email accounts information inorder to receive the actual email address that matches to eachcorresponding name. If more than one match is found for a single query,all returned values are kept.

The next step is to populate these addresses to the recipient tab. Ifonly one email address is found then this one is set automatically tothe “To . . . ” field. If more than one email address is found then,according to the configuration, all recipients may be set to the “To . .. ” field, or the first one (in alphabetical order or by some sortingalgorithm) may be set to the “To . . . ” field while all the others tothe “Cc . . . ” field, or the list of potential email addresses ismatched to certain patterns and an automatic filling is doneaccordingly, or a user dialog is started for him or her to make his orher choice. Finally, the user may be informed that actions are finishedand the user may review the recipients list for verification. This stepis useful for cases where the queries returned more than one result foreach one, e. g. antonios.agathangelos@unify.com andgeorge.agathangelos@unify.com for queering the name “agathangelos”. Thefinal step can be avoided if accurate rules like using a pattern like“Hello Mr. Surname First name,” are chosen to be used, which will have“one to one” matching queries only.

In case that a contact person extracted by the method has more than oneemail address, e.g., for personal and business use, the method mayfurther apply additional patterns or even more sophisticatedtechnologies such as text/context analysis techniques so as to enablethe method to decide on whether a personal or professional context ispresent, in the email, and choose an appropriate address from aplurality of said recipient's addresses.

Now, the invention is described in more detail, making reference to apreferred embodiment of the invention.

FIG. 1 shows a block diagram of a general outline of an email client 100according to an embodiment the invention. Email client 100 includes auser interface (UI) 110, a main algorithm 120, an email accountdirectory 130, a configuration database 140, and a configuration module150. It should be evident that email client 100 may include furtherfunctional units which, however, are omitted for the sake of convenienceand not making unclear the scope and meaning of the present invention.Flow of data and/or control is illustrated by arrows in FIG. 1. It is tobe noted that the direction of data and/or command flow is onlyschematic and exemplary and should not be construed to limit theinvention in any regard.

Next, email client user interface (UI) 110 is further explainedreferring to an exemplary embodiment of the invention. In this regard,FIG. 2 shows a representation of email client user interface 110 asoccurring, e.g., on a computer screen or the like, according to thisembodiment of the invention.

Email client 100 generates a window or screen 200 which allows a user(not shown) to define, formulate, format, and send an email. Emailclient screen 200 includes numerous control buttons, menus, and inputboxes manipulable by the user.

A main input box 210 allows a user to formulate his or her message intext form, and represents the main content or body of the message. It isto be noted that, while the invention is described here to make use oftext content only, main input box 210 may include formatted text and/orembedded media as well. A scroll bar 215 allows to shift contentincluded in input area 210 up and down. A subject input box 220 allows auser to enter a subject of the message in text form. Main input box 210and subject input box 220 contain the body and subject of the message,respectively, which represent content fields of the message's datastructure, altogether forming a content area 240 in the sense of thepresent invention.

It is to be understood that input boxes and other graphical elementssuch as control buttons or menus shown in window 200 represent thecurrent contents of certain data fields of the message as a datastructure. In other words, data currently populating the email's datafields instantaneously show up, e.g., as text in respective input boxes,highlighted menu item in respective dropdown or scroll menus, shadowingstatus of respective control buttons, or the like, in window 200. Inturn, any user action such as text input, menu selection or button clickinstantaneously changes the contents of the respective data fields ofthe message in this pre-sent state, and is reflected by the contents orstatus of the respective input box, menu or control button. Therefore,contents or status of graphical elements of window 200 may be understoodas a synonym of contents of the respective data elements of the message,and vice versa.

An address area 230 is formed by entries of a sender address input box232 (“From”), a main recipient address input box 234 (“To”), a secondaryrecipient address input box 236 (“Cc”), and a hidden recipient addressinput box 238 (“Bcc”). The “From”, “To”, and “Bcc” input boxes 232, 234,238 show one address each while “Cc” input box 236 shows two addresseswhich is, however, an assumption in this example and shall not limit theinvention in any regard. It is noted that “From:”, “To:”, “Cc:” and“Bcc:” buttons 233, 235, 237, 239 placed in front of the respectiveaddress input boxes 232, 234, 236, 238 may trigger opening email accountdirectory 130 (FIG. 1) in a further window, dialog box, menu or thelike, so as to manually search and/or select addresses therefrom and putthem into the respective input box and/or input boxes 232, 234, 236,238.

A control block 250 includes numerous menus and control buttons forformatting the message text in main input box 210, for undoing andrepeating actions on the message text in main input box 210, to addattachments or predetermined graphic elements such as emoticons, andalso includes a “Recip. auto filling” control button 260 for triggeringan automatic recipient address filling functionality to be describedlater. A “Send” button 270 is to manually trigger sending the finishedmessage to the selected recipients.

As will be later described in more details, “Recip. auto filling”control button 260 is for enabling and controlling the automaticrecipient address filling functionality which forms a central teachingof the present application. In short, such functionality is designed toparse the content of the main input box 210, i.e., the main content ofthe message, into content chunks 280 so as to detect configuredidentifiers such as “Mr.”, “Mrs.”, “Dr.” and the like, extract nameportions following those identifiers, search matching entries from emailaccount directory 130, and filling them into recipient address inputboxes (i.e., respective recipient address fields of the message's datastructure). In the example illustrated in FIG. 2, four content chunks280 have been highlighted which include an identifier pattern and asubsequent key word or name portion. Mr., Dr. and Mrs. may be configuredidentifiers 280 that the automatic recipient address fillingfunctionality searches so that it is able to acquire the key word or keywords following the identifiers. Based on the acquired key word or keywords, the filling functionality recovers the data/addresses to beinserted in the address input box or address input boxes 232, 234, 236,238. It is noted that the automatically filled address fields representor include a recipient address proposal (symbolized by double-dottedchain line area 290 in FIG. 2) in the sense of the present inventionwhich may or may not be accepted by the user. It will further be notedthat this example uses a very simple pattern including onlytitles/salutations as identifier patterns, and rather simple rules suchas that the very first name extracted go to the “To” field, furthernames go to the “Cc” field, and names extracted just above acomplimentary close go to the “Bcc” field. Vagueness is accepted herebecause the proposal 290 may be changed by the user at any time.

FIG. 3 gives a more detailed illustration of the email client generalstructure of FIG. 1 according to an embodiment of the invention. FIG. 3is similar to FIG. 2, however, FIG. 3 provides additional indication offurther functionality.

In FIG. 3, email client 100 is illustrated with its email client userinterface 110, main algorithm 120, account directory 130, configurationdatabase 140, and configuration module. User interface 110 includes ascreen 200 with elements similar to those of FIG. 2, however, enteredcontent in main input box 210 and subject input box 220 as well asgenerated recipient address proposal 290 in “To” input box 234 and “Cc”input box 236 differ from the example shown in FIG. 2. Moreover, a “Bcc”input box is not shown in the present example of FIG. 3 which, however,does not exclude the possibility that such “Bcc” input box may be poppedup on behalf of the user, or automatically when the main algorithmdecides that a hidden recipient address is to be included in therespective data field.

As shown in FIG. 3, main algorithm 120 includes an algorithm feature 320which may be understood to be a plug-in, add-on, or the like, of mainalgorithm 120, executing a process representing a functionality of themethod of the present invention. Then, email account directory 130includes an email address list 330 with a plurality of email addresseswhich have been previously stored manually by the user or automaticallyby the client. Furthermore, configuration database 140 includes arule/pattern catalogue 340 of pattern identifiers and associatedallocation rules. In the example depicted in FIG. 3, three patternidentifiers (Pattern identifier 1, Pattern identifier 2, and Patternidentifier 3) and three respectively associated allocation rules areprovided in rule/pattern catalogue 340. A first allocation rule which isshortly expressed as “Identifier 1 goes to To:” means that an emailaddress matching a name portion extracted in the context of patternidentifier 1 is to be assumed as a main recipient address (“To”), andproposed for inclusion in the respective data filed of the email.Likewise, a second allocation rule which is shortly expressed as“Identifier 2 goes to Cc:” means that an email address matching a nameportion extracted in the context of pattern identifier 2 is to beassumed as a secondary recipient address (“Cc”), and proposed forinclusion in the respective data filed of the email. Finally, a thirdallocation rule which is shortly expressed as “Identifier 3 goes toBcc:” means that an email address matching a name portion extracted inthe context of pattern identifier 3 is to be assumed as a hiddenrecipient address (“Bcc”), and proposed for inclusion in the respectivedata filed of the email.

In this example, the expression “in the context of pattern identifier .. . ” may be understood as “directly following pattern identifier . . .”. As shown in FIG. 3, the word “Hello” is defined as pattern identifier1, so “Mr. Bob” would be extracted as a name part as it directly followsthe word “Hello”, and an email address matching the name part “Mr. Bob”would be looked up in email address list 330, and a matching emailaddress would be added to a main recipient address area of recipientaddress proposal 290. Furthermore, the expression “and” is defined aspattern identifier 2 where it follows a previously identified patternidentifier and name portion, so “Mr. Peter” would be extracted as a namepart as it directly follows “Hello Mr. Bob and”, and an email addressmatching the name part “Mr. Peter” would be looked up in email addresslist 330, and a matching email address would be added to a secondaryrecipient address area of, forming part of recipient address proposal290. However, these patterns and rules are strictly exemplary and aremeant to explain this feature of the invention rather than limit thesame. For example, the expressions “P.S.” and “just for yourinformation” may be defined as pattern identifiers, and the associatedallocation rule could prescribe that a name part is to be extracted frombetween these two expression, as indicated in FIG. 2.

As further shown in FIG. 3, if a user activates the Recip auto fillingbutton 270 by, e.g., clicking on it by a mouse curser, entering aprescribed keyboard command, or the like, configuration module 150 isactivated and a configuration menu 350 is popped up. Configuration menu350 offers a plurality of selectable menu items for

-   -   i. enabling the feature,    -   ii. disabling the feature,    -   iii. inserting a configuration pattern,    -   iv. editing existing patterns,    -   v. deleting all patterns,    -   vi. autofill address input boxes according to rules regarding        To/Cc/Bcc, and    -   vii. exiting the menu.

Now, implications and functions of configuration menu 350 are describedin more detail.

Selecting the “Enable feature” menu item of configuration menu 350activates an algorithm feature 320 of the email client's main algorithm120 which will then run in the background, executing a processrepresenting the recipient automatic filling method of the presentinvention until the user selects the “Disabling feature” menu item. Inother words, selecting the “Enable feature” menu item of configurationmenu 350 starts main algorithm feature 320 while selecting the “Disablefeature” menu item stops main algorithm feature 320.

When enabled, algorithm feature 320 executes a process representing acore of the recipient automatic filling method of the present invention.Feature 320 makes use of contact list 330 stored in email accountdirectory 130 and makes further use of pattern identifiers andassociated allocation rules stored in rule/pattern catalogue 340 ofconfiguration database 140. Described in short, algorithm feature 320reads the identifiers from the configuration database 140, looksperiodically for the rules in the email content as entered in main inputbox 210, follows a hit by query for a matching email address in addresslist 330, stores a matching email address in respective areas ofrecipient address proposal 290 in accordance with the allocation rulesset in rule/pattern catalogue 340 of configuration database 140, and inthe end sets the addresses stored in the recipient address proposal 290to the allocated input boxes 234, 236, 238 which means filling them intothe respective address fields of the message.

It is to be noted that, in order to avoid distraction while writing theemail content, filling of recipient address input boxes 234, 236, 238may be subject to explicit user command, i.e., selecting the “autofillrules To/Cc/Bcc” item in configuration menu 350. When selected, feature320 fills the respective input boxes. Even if not shown in the drawing,recipient addresses generated by the algorithm may be highlighted inrecipient address input boxes 234, 236, 238 so as to distinguish themfrom recipient addresses which have already entered manually orautomatically before. Then, feature 320 pops up a dialog box 360allowing the user to verify the recipient address proposal 290 byselecting a “Yes” button 362, or discard the recipient address proposal290 by selecting a “No” button 364. If the user discards the proposal,the proposed recipient addresses are removed. If the user verifies theproposal, the proposed recipient addresses are kept while highlightingof proposed addresses, as far as applied, is undone.

The present invention should not be construed to be limited to the abovefunctionality. In an alternative example of functionality, is possibleto instantaneously fill an identified recipient address to the allocatedinput box (tab) 234, 236, 238, optionally highlighted, preferablyavoiding duplicate entries, and the user may or may not edit the inputboxes as required, instantaneously, or only after finishing the emailcontent. In that case, selecting the “autofill rules To/Cc/Bcc” item inconfiguration menu 350 may trigger a review of addresses filled inrecipient address input boxes 234, 236, 238, i.e., and the algorithmfeature 320 is run a last time so as to fill the input boxes withrecipient addresses according to the current state of email content.Optionally the input boxes are cleared prior to running feature 320.

In a further variation of the above example, before filling theaddresses of recipient address proposal 290 into the respective inputboxes, a dialog box different from dialog box 360 shown in FIG. 3 may begenerated and popped up, including a preliminary address listrepresenting the recipient address proposal 290, said preliminaryaddress list including markers indicating which address field eachaddress is preliminarily allocated to, giving the user a tool to editthe proposal by deleting individual addresses, or by reallocating anindividual address to another address area (e.g., “To” field instead of“Cc” field, etc.), and only after user verification the proposal isfilled into the respective input boxes. In a yet further variation, thepreliminary address list mentioned above may be split into sub-lists,e.g., a preliminary “To” address sub-list, a preliminary “Cc” addresssub-list, and a preliminary “Bcc” address sub-list. These sub-lists maybe shown in parallel besides each other, and the user may be given atool to delete individual addresses or to shift individual addressesfrom one address sub-list to another.

It will be noted that a number of pattern identifiers and associatedrules may be stored by default in configuration database 140 so that themethod (the algorithm feature) 320 may work even if the user decides notto edit the configuration database 140.

When an email is sent, the feature 320 may be kept activated for thenext email to be written, or may alternatively be disabledautomatically. These options may be settable by the user through afurther configuration task.

Next, a process 400 will be described with reference to FIGS. 4A-4C,forming an embodiment of the present invention. Process 400 includes aconfiguration section 400 a, a analyzing section 400 b, and a finalisingsection 400 c. In this embodiment, feature 320 is assumed to be executedby a dedicated apparatus. The invention, however, is not limited tothis. The apparatus may be part of a device executing the main algorithmof email client 100 or the email client 100 as a whole, adapted and/orexpanded by a plug-in, add-on, app or the like, i.e., by some softwareitem, or some hardware extension, chip, card, stick, dongle, or others.Any step of the method, hence, may be taken as a feature of theapparatus, and vice versa, where applicable.

First, configuration section 400a of process 400 will be described withreference to FIG. 4A.

Beginning of process 400 may be assumed to be triggered by calling menu350 (FIG. 3) for the first time by clicking control button 270. First,then, a step S410 is provided where the user sets configuration rulesfor pattern identifiers and cross-sets them with the three availablerecipient address spaces (To . . . Cc . . . Bcc . . . ) (340 in FIG. 3).Step 410 may be called automatically or upon user demand, e.g., byselecting one of the insert, edit, or delete patterns (menu items iii,iv, v of configuration menu 350 in FIG. 3). In other words, step S410may include a query (optionally, in the form of an interruptperiodically produced during run of later sections of the process)judging whether a user has selected a respective menu item, and startingthe associated configuration task. Step S410 may be finished by useraction (e.g., clicking a “Done” button in a rule defining menu), or justby skipping any configuration task.

After step S410, follows step S412 judging whether or not validconfiguration rules are set. If any invalid configuration rule was found(“NO” in step S412), the process continues to step S420 determining thatthe apparatus mentioned above cannot be enabled. Step S420 may include auser dialog informing the user that configuration has failed, invitingfor further user action.

Thereafter, step S422 judges whether or not a configuration is to beretried (e.g., by evaluating user action from a user dialog generated instep S420). If the answer in step S422 is “YES”, the process returns tostep S410 while if the answer in step S422 is “NO”, the process ends.

If in Step S412 any configuration rule entry was found to be valid(“YES” in step S412), the process continues to step S430 giving the useran opportunity to enabling the apparatus by, e.g., popping up menu 350again. In case user should not enable the apparatus, the process remainsat hold. Exiting menu 350 without enabling the apparatus may end theprocess for this time.

Step S432 follows where the user may start writing new email content.I.e., at this point, the user has enabled the feature (apparatus) andexited menu 350. At this point, configuration section 400 a of process400 is finished, and the process enters into analyzing section 400 billustrated in FIG. 4B.

Referring to FIG. 4B, entering analyzing section 400 a, step S440 iscalled which parses content of the email presently being written,looking for preconfigured identifiers. This step is to be explained inmore detail. In the sense of the present invention, parsing of step S440means dividing the email content into content chunks, and then, lookingmeans selecting, one by one, a content chunk and deciding whether or notsaid content chunk matches a predefined addressee identifier pattern.Hence, step S440 may return any content chunk which matches at least oneof addressee identifier patterns which may be represented, in thepresent example, by pattern identifiers 1, 2, 3 set in rule/patterncatalogue 340 in FIG. 3.

Then, step S442 judges whether or not at least one identifier wasdetected, i.e., whether or not any content chunk matching at least oneof said addressee identifier patterns was returned by step S440. If noidentifier was detected (“NO” in step S442), the process continues tostep S450 judging whether or not the user has finished. User finishingmay be affirmed when, e.g., “Send” button 270 was clicked, or menu 350was called again and the “Disable feature” was selected by the user. Incase user has not finished (“NO” in step S450), the process returns tostep S440. Otherwise (“YES” in step S450), the process continues to stepS452 editing a log file that no identifier was used, followed by stepS454 popping up a user dialog including the log content. Then, theprocess ends.

If an identifier (i.e., at least one identifier) was detected (“YES” instep S442), the process continues to step S460 extracting key wordsafter the respective identifiers. These key words are interpreted by theprocess as name portions of the respective content chunks. It is to benoted that extracting the key words from the content chunk at arespective prescribed location or under a respective prescribedcondition within the pattern, is to be understood as part of the patternper se, as defined in rule/pattern catalogue 340. There may be patternswhich demand extracting the key words in front of the respectiveidentifier, or between two identifiers. Patterns may prescribe thatcertain skipwords (e.g., words like “friend”, “brother”, “sister”,“collegue”, “valued”, “honorable”, “beloved”, etc. which may frequentlyfollow a pattern identifier like “Dear”) are skipped when extracting aname portion, making use of skipword collections which may be definedindependently in rule/pattern catalogue 340, and may be editable aswell.

Steps S442 and S460 may be repeated for each single content chunkreturned by step S440 so that step S440 returns any name portion, linkedwith the identifier in which context it was found (cf. dashed returnpath R461 in FIG. 4B). Duplicates may be removed before continuing theprocess.

Having extracted the key words in step S460, the process continues tostep S462 judging whether or not the user has finished (see afore stepS450, for this part). If not (“NO” in step S462), the process returns tostep S440.

If the user has finished the feature (“YES” in step S462), the processcontinues to step S464 using the key words to make a query to emailaccounts directory 130. Also this step S464 earns some detailedconsideration. A first part of step S464 compares the extracted keywords (i.e., name portions) with each entry of entries in the addresslist 330 stored in email accounts directory 130. Then, a second part ofstep S464 judges whether or not any of the extracted key words matches aparticular entry, and if so, in a third part extracts any email addresscollated in said particular entry. In other words, step S464 returns anyemail address matching any extracted key word, linked with therespective identifiers in which context the key words were found. Onlyaddresses suitable for the particular email protocol used (e.g., SMTP)may be chosen by the process. At this point, analyzing section 400 b ofprocess 400 is finished, and the process enters into finalising section400 c illustrated in FIG. 4C which is made reference to, in thefollowing.

Referring to FIG. 4C entering finalising section 400 c, step S470 isprovided judging whether or not a valid email address was returned fromstep S464. If no valid email address was returned (“NO” in step S470),the process continues to step S480 editing the log file that norecipient address was found in the contact directory (email accountdirectory 130), followed by step S482 popping up a user dialog includingthe log content. Then, the process ends.

If a valid email address (i.e., at least one valid email address) wasreturned (“YES” in step S470), the process continues to step S490setting the email addresses to the appropriate email address spaces(recipient address input boxes 234, 236, 238) based on the preconfiguredrules from configuration database 140, then continues further to stepS492 editing the log file that a recipient entry was set (i.e., at leastone recipient address was filled into respective recipient address inputboxes 234, 236, 238), followed by step S494 popping up a user dialogincluding the log content. The user dialog mentioned in step S494 maycorrespond to dialog box 360 of FIG. 3. Then, the process ends.

It is to be noted that the division of process 400 into sections 400 a,400 b, 400 c is clearly arbitrary and for descriptive reasons only whichby no means imply any functional limitations. For example, step S432described as final step of configuration section 400 a may as well beunderstood to form part of the analyzing section 400 b. Similarly, stepS464 described as final step of analyzing section 400 b may as well beunderstood to form part of the finalising section 400 c.

In FIG. 5, a flow chart of an example process 500 according to a furtherembodiment of the present invention is shown. As shown in FIG. 5, afterstart of the process 500, in a user configuration step S510, a user setsa configuration and enables functionality of the process. I.e., the useris given the opportunity, by automatically prompting a user dialog(e.g., menu 350 of FIG. 3) or by explicitly initiating such step, toconfigure addressee identifier patterns mentioned above which enablesthe parsing and identifying steps as described later on. The userconfiguration step S510 may be skipped at the beginning as defaultaddressee identifier patterns may be defined beforehand. On the otherside, the user configuration step may be called at any point of theprocess, by the user, e. g., by selecting some menu item offered by aclient executing the process. Any of a user-configured addresseeidentifier pattern and a previously defined addressee identifier patternmay be understood to be a predefined addressee identifier pattern, inthe sense of the present invention. Additionally, the user may alsoconfigure in step S510 which account directory or directories may beused to find a matching email address. If no account directory isconfigured in step S510, the process may rely on any account directoryfound by the email client as an account directory assigned to the user,or an account directory defined beforehand. Any of a user-configuredaccount directory and an account directory found or defined beforehandmay be understood to be a predefined directory, in the sense of thepresent invention.

Thereafter, in an email writing start step S520, the user starts writinga new email. In other words, the process 500 remains in a waiting stateat this point until it is recognized in step 120 that the user startswriting a new email. Only if the recognizing is made in step S520 thefollowing functionality of the process may begin to work.

After the user is recognized to having started writing a new email instep 120, in a parsing step S530, content of the email is parsed lookingfor identifiers. In other words, the content of the email is dividedinto content chunks, a content chunk is selected, and it is decidedwhether said content chunk matches a predefined addressee identifierpattern. The selecting and deciding is executed for every content chunkone by one.

In step S535, it is judges whether or not identifiers are found. Inother words, step S535 returns a positive answer (YES) if at least onecontent chunk has been decided in step S530 to match a predefinedaddressee identifier pattern. On the other hand, step S535 returns anegative answer (NO) if no content chunk has been decided in step S530to match a predefined addressee identifier pattern. If step S535 returnsa “NO”, a no-pattern edit step S540 is executed where a log file isedited that no pattern was used. If step S535 returns a “YES”, anextracting step S550 follows to extract the names and make a query to anaccount directory for retrieving an email address. In other words, stepS535 includes extracting a name portion from the content chunk underprocessing, and comparing the extracted name portion with at least oneentry of entries of the directory. Then, in step S555 the process judgeswhether or not the comparing in step S550 has returned an email address.In other words, in step S555 it is judged whether or not the nameportion matches the entry of the directory. Of course, the directory mayinclude a multiplicity of entries, and the comparing and judging stepsmay be repeated for each entry one by one which may return a pluralityof email address matchings. In other words, step S555 returns a positiveanswer (YES) if the name portion has been decided to match at least oneentry of a predefined directory. On the other hand, step S555 returns anegative answer (NO) if the name portion has been decided not to matchan entry of the predefined directory.

If step S555 returns a “NO”, a no-recipient edit step S560 is executedwhere a log file is edited that no recipient address was found in thecontact directory (i. e., the predefined directory). If step S555returns a “YES”, an address setting step S570 is executed. Thereafter, aset-entry edit step S580 is executed where a log file is edited that arecipient address is set and needs user verification. In other words,the log file now includes a recipient address proposal based on anaddress or addresses which was/were stored in the entry of thedirectory. It is to be mentioned that only addresses which are suitablefor email messaging are set in step S570.

From steps S540, S560, or S580 the process leads to a dialog step S590where a a dialog with log content is popped up to the user. In otherwords, the user is asked to verify the log file which represents therecipient address proposal in the sense of the present invention. Thedialog function of step S590 is linked with a recipient address fieldfunction of the email client such that the verified recipient addressproposal is finally filled, as verified addresses, into the recipientaddress field of the message. In a user interface, the verifiedaddresses show up in respective input boxes as shown in FIGS. 2, 3.After that, the process ends.

If more than one name is to be extracted in step S550, unless any nameportion to be extracted has been extracted, the process may return tostep S550 after steps S560, S580, respectively, which is indicated byrespective return paths R565, R585 shown in dashed lines. Likewise, theextracting in step S550 may yield a list of name portions which may bequeried, one by one, and processed by steps S555 through S580 in whichcase, unless any name portion to be processed is processed, theprocessing may return to step S550 after steps S560, S580, respectively,via respective return paths which coincide, in the drawing, with returnpaths R565, R585 but do not hook into the extract part but the querypart of step S550. Alternatively, a list of names may be queried to thedirectory as a whole which may return a list of email addresses, inwhich case returning to step S550 via return paths R565, R585 may beomitted.

As indicated in FIG. 5 by dotted lines, after any of steps S540, S560,S580, the process may return to step S530 via respective return pathsR543, R563, R583 to parse again the content of the email. This loop maybe run through in predetermined time intervals until the processrecognizes that the user has ended writing the email by, e.g., clickinga send button (see button 270 in FIGS. 2, 3).

As a further embodiment of the invention, algorithm feature 320 isfurther adapted to automatically fill a sender address field asrepresented by sender address input box 232, instead of or in additionto automatically filling recipient address fields according to thepreviously described embodiments. E.g., a user may use different senderaddresses for personal and professional purposes, each of whichaddresses being provided, e.g., by email account directory 130 or aseparate directory of email client 100. Process 400 or process 500 maybe adapted to recognize patterns in a content area used in personal andprofessional contexts, and propose the appropriate sender address (or aranked list of sender addresses for selection if ambiguous). Thepatterns may include typical private identifiers like “With love,” orprofessional identifiers like “Sincerely,”. Moreover, patterns may alsoinclude evaluating the setting of tags, categories or labels indirectory entries represented by items in recipient address input boxes234, 236, 238, said tags, categories or labels including “family”,“friends”, or the like as an indication to assume a personal context,and “colleagues”, “customers”, “suppliers” or the like as an indicationto assume a professional context. Colleagues within a company may beaddressed from an internal email account by an internal email senderaddress while family members may be addressed from a private emailaccount by a private email sender address, fellows of a club, society orthe like may be addressed from an email account associated to said club,society or the like, by a specialized email sender address, and so on.Unless stated otherwise or obviously inappropriate, any featuredescribed in the context of any embodiment of the invention may beincluded in or adapted to the present embodiment. The automatic senderaddress filling method of this embodiment may be realized separately orintegrated with the automatic recipient address filling method of anyembodiment described before.

For illustrating the concept in real application, an example isdescribed in the following. The example relates to an Outlook* clientintegration, as a further embodiment of the invention.

An Outlook* add-in offers the opportunity to parse the content of a newemail creation via a new Outlook._MailItem* object configured accordingto the present invention. While the user types the mail content a timerruns periodically and checks if the content contains the identifiersmentioned in the configuration step, or, when the user finishes theemail content, activates the add-in functionality through a button. Ifthis is true then the add-in will catch the name (which is next in thesequence) according to the pattern set in configuration rules. MSOutlook* offers additionally internal Contacts or Exchange Server as aresource for querying and matching the name to the corresponding emailaddress. Then this will be appended in “To” field of the new mail formwith a method function according to the present invention which, forexample, may appear under the name “message.To.Add (email_address)”.Finally the add-in will rise a pop up dialog with either prompting forverification of the recipients list set and proceed with sending themail or with reporting error in an exception case. A similar concept canbe realised as a web browser add-in for web mail case.

The method described herein may easily be adapted to a plurality ofrequirements. For example, it is easy to understand that the inventionis not limited to the pattern identifiers and allocation rules mentionedabove. There may be rules prescribing that any message sent to a certainperson or group of persons automatically is forwarded to a certain otherperson or other group of persons.

The invention is further not limited to parsing the content of the maininput box. It is conceivable that also the content of the subject inputbox 220 is analyzed for identifiers. For example, it may be usual in acompany that file numbers which a message belongs to are placed betweencertain characters such as braces, square or angle brackets, or thelike, or are introduced by some characteristic passage such as<company_name> & “file no.:”, or the like. In such cases, the filenumber may be extracted from the subject field, and a function may beprovided for extracting contact persons from the company's filemanagement database and adding data found in the respective contactentry to the respective data field(s) of the message. Further extractingand allocation rules are easily conceivable by a skilled person in thefield.

Hitherto, as mentioned above, there was no way to automatically fill the“To” field of an email, especially if there are a lot of (typicallydifferent) personalised emails to be sent. There was the possibility touse the auto-complete feature, or to use an OUTLOOK* form to createpersonalised forms, which include the email address of the recipient.

According to the present invention, it is proposed to use the context ofthe email and to extract the required information to populate the “To”field therewith. I.e., most emails follow more or less fixed patterns:“Hello Mr. XYZ”, “@ Ms. ABC” or something similar. According to theinvention, such patterns are used to configure an algorithm (e.g. anOUTLOOK* plug-in) or may be used as rules by this algorithm,respectively. The algorithm derives attributes of the recipient and,based on these attributes, derives the email address to be used. Therules may be set up, modified and/or deleted by the user and may be veryprecise.

The context of the email is parsed and analysed by the algorithm, as setforth in the afore description and appended claims. If there is at leastone match with a pattern, the name of the recipient is extracted. Thename is then used to query a directory and the “To” field is populatedwith the retrieved address. If this yields more than one address, alladdresses are kept and the user has to decide whether to use alladdresses or to have just the first one to go into the “To” field andthe remaining addresses to go into the “Cc” field. In a further step theuser is notified about the finished task and is enabled to review thelist of recipients. In other words, rules are set up to exploitfrequently used patterns, to look up the recipient's address and then topopulate the “To” field (or any other addressee field) of an email.

The present method defines a way of automatically setting recipientand/or sender data in an electronic message like an email or the like byexploiting certain patterns in message content that can be used incombination to certain tools like account directory or contact lists.The advantages are manifold. First it eliminates that time someonespends to set these data. Even if this is just a few seconds, takinginto account that a common person writes hundreds of emails per day or acompany sending to its thousands or even millions of customers apersonal mail, the benefit becomes obvious. Second it is generic and canbe very easily applied to all email or other messaging clients eitherthey are desktop applications like Outlook* or web-based like Gmail* oreven mobile application clients. Additionally another advantage is thatit can be used in mobile devices in which searching the appropriateemail directory is tricky and time-consuming and becomes even harder dueto display and networking limitations. Furthermore, it eliminates therisk of making a mistake in the recipients list which is likely to occurwhen the mailing list includes persons with identical or very similarnames and someone uses the auto-complete feature or a very quick manualquery in the directory list.

The present method is generally applicable to any fields ofcommunication.

It is noted that email client 100 is a mere example of a messagingclient in general, and any messaging client is, in principle, able tomake use of the invention described before, per se or with adjustmentsand technical adaptations which should be obvious to a person skilled inthe field. Messaging clients may be, besides email clients, SMS or othertext messaging clients, SMTP clients, personal messaging clients asstand-alone services such as WhatsApp*, Kik Messenger*, Snapchat* or thelike, or as part of social media networks such as Twitter*, Facebook*,Instagram* or the like, instant messaging clients, paging serviceclients, but are not limited thereby.

Obviously, various applications of the present invention may becomeapparent to person skilled in the art, based on the informationdisclosed in the present specification, which might not be mentionedexplicitly but are fully covered by the scope of the presentapplication. For example, while the invention is described above to makeuse of text content only, the inventive method may also make use of anyinformation included in any content field of the message, be itexplicit, embedded, or attached.

Specific features of the invention as described above with reference tothe exemplary embodiments, may also be implemented in other embodiments,variations or modifications, unless such implementations impose theirown prohibitions.

1-17. (canceled)
 18. A computer-implemented method of improvingelectronic messaging, the method comprising: analyzing a content of amessage; extracting a sender name portion from the content of themessage; comparing the sender name portion with a directory entry;generating a sender address proposal based on the directory entry; andautomatically filling an address field with the sender address proposal.19. The computer-implemented method of claim 18, wherein analyzing thecontent of the message further comprises: dividing a content area forthe content into one or more content chunks; and determining that atleast one of the one or more content chunks matches a predefinedaddressee identifier pattern, wherein extracting the sender name portioncomprises extracting the sender name portion from the at least one ofthe one or more content chunks.
 20. The computer-implemented method ofclaim 18, further comprising: breaking the sender name portion into namefractions corresponding to respective data fields in the directoryentry; and comparing the sender name portion with the directory entryusing the name fractions.
 21. The computer-implemented method of claim20, wherein breaking the sender name portion into name fractionscomprises breaking the sender name portion into a prename, a surname, atitle, or a salutation.
 22. The computer-implemented method of claim 18,wherein generating the sender address proposal comprises generating asender address list.
 23. The computer-implemented method of claim 18,wherein the method is executed at a predefined point of time.
 24. Thecomputer-implemented method of claim 18, wherein the method is executedin the form of an email plug-in, a browser add-on, or a mobile messagingapplication.
 25. A non-transitory, computer-readable medium, storinginstructions that, when executed by a processor, cause: analyzing acontent of a message; extracting a sender name portion from the contentof the message; comparing the sender name portion with a directoryentry; generating a sender address proposal based on the directoryentry; and automatically filling an address field with the senderaddress proposal.
 26. The non-transitory, computer-readable medium ofclaim 25, storing further instructions that, when executed by theprocessor, cause: dividing a content area for the content into one ormore content chunks; and determining that at least one of the one ormore content chunks matches a predefined addressee identifier pattern,wherein extracting the sender name portion comprises extracting thesender name portion from the at least one of the one or more contentchunks.
 27. The non-transitory, computer-readable medium of claim 25,storing further instructions that, when executed by the processor,cause: breaking the sender name portion into name fractionscorresponding to respective data fields in the directory entry; andcomparing the sender name portion with the directory entry using thename fractions.
 28. The non-transitory, computer-readable medium ofclaim 27, wherein breaking the sender name portion into name fractionscomprises breaking the sender name portion into a prename, a surname, atitle, or a salutation.
 29. The non-transitory, computer-readable mediumof claim 25, wherein generating the sender address proposal comprisesgenerating a sender address list.
 30. The non-transitory,computer-readable medium of claim 25, wherein the instructions areexecuted at a predefined point of time.
 31. The non-transitory,computer-readable medium of claim 25, wherein the method is executed inthe form of an email plug-in, a browser add-on, or a mobile messagingapplication.
 32. A messaging system, comprising: a processor; a memoryoperatively connected to the processor and storing instructions that,when executed by the processor, cause: analyzing a content of a message;extracting a sender name portion from the content of the message;comparing the sender name portion with a directory entry; generating asender address proposal based on the directory entry; and automaticallyfilling an address field with the sender address proposal.
 33. Themessaging system of claim 32, wherein the memory stores furtherinstructions that, when executed by the processor, cause: dividing acontent area for the content into one or more content chunks; anddetermining that at least one of the one or more content chunks matchesa predefined addressee identifier pattern, wherein extracting the sendername portion comprises extracting the sender name portion from the atleast one of the one or more content chunks.
 34. The messaging system ofclaim 32, wherein the memory stores further instructions that, whenexecuted by the processor, cause: breaking the sender name portion intoname fractions corresponding to respective data fields in the directoryentry; and comparing the sender name portion with the directory entryusing the name fractions.
 35. The messaging system of claim 34, whereinbreaking the sender name portion into name fractions comprises breakingthe sender name portion into a prename, a surname, a title, or asalutation.
 36. The messaging system of claim 32, wherein theinstructions are executed at a predefined point of time.
 37. Themessaging system of claim 32, wherein the instructions are executed inthe form of an email plug-in, a browser add-on, or a mobile messagingapplication.